home *** CD-ROM | disk | FTP | other *** search
/ Archive Magazine CD 1995 / Archive Magazine CD 1995.iso / discs / prog_disc / volume_8 / issue_06 / risc_os / Wimp / Switcher < prev    next >
Encoding:
Text File  |  1988-12-06  |  6.7 KB  |  147 lines
  1. > Wimp.Switcher
  2.  
  3. New Calls
  4. ---------
  5.  
  6.         Memory Management
  7.         Wimp_SlotSize
  8.         Interactive slot resizing
  9.         Wimp_ClaimFreeMemory
  10.  
  11.  
  12. Memory Management
  13. -----------------
  14.  
  15. While the Wimp is running, it maintains a pool of free memory pages, which
  16. can become available for programs which need to use the application area.
  17. Each task takes a portion of the available application memory (0 if the task
  18. is a module!), and the Wimp pages the application memory so that each of the
  19. tasks running in application space gets a block of memory starting at &8000
  20. (when it is paged in). 
  21.  
  22. The Wimp's free pool can also be used to give memory to other areas of the
  23. machine, if required (eg. if the RMA expands or the screen memory needs to
  24. increase), so providing much greater flexibility than was available under
  25. Arthur 1.20 (ie. 'No room in RMA' occurs far less often!).
  26.  
  27. The desktop provides a 'Switcher' icon on the extreme right of the icon bar,
  28. which allows a task/memory display window to be opened.  This provides a
  29. display of the currently running Wimp tasks and how much application memory
  30. they are using, as well as an overall memory map showing where the memory in
  31. the machine is currently being used.
  32.  
  33. By dragging either the 'Next' or the 'Free' bar it is possible to tell the
  34. Wimp how much memory should be used for the next task running in application
  35. space, and how much should be reserved for later.  A SWI is provided to alter
  36. the amount of memory given to the next application, as well as to alter the
  37. amount of memory currently available in application space.
  38.  
  39. There is also a message-passing system which allows a task to communicate
  40. with the switcher so that the user can drag the task's memory slot display to
  41. change its slot size.
  42.  
  43.  
  44. Wimp_SlotSize
  45. -------------
  46.  
  47. The following SWI can be used to alter the amount of memory currently
  48. available, or the amount to be used by the next task starting up:
  49.  
  50.         Wimp_SlotSize
  51.         Entry:  R0 = size of current slot (-1 ==> just read setting)
  52.                 R1 = size of next slot    (-1 ==> just read setting)
  53.         Exit:   R0 = size of current slot
  54.                 R1 = size of next slot
  55.                 R2 = size of free pool
  56.  
  57.         The Wimp does not perform the usual MOS actions which are used to
  58.         check whether the application space is in use (ie. it does not send
  59.         round a Service_Memory to see if the memory is in use, and it doesn't
  60.         object if the CAO pointer is inside application space).
  61.  
  62.         On exit the OS_ChangeEnvironment parameters 'MemoryLimit' and
  63.         'ApplicationSpaceSize' are updated.  Note that the application space
  64.         cannot be increased or decreased if ApplicationSpaceSize >
  65.         MemoryLimit (eg. if Twin is running above the current application),
  66.         since this would confuse the program running above MemoryLimit).
  67.  
  68. Using this call, it is possible to change the amount of memory to be used by
  69. the current task, as long as the current application is able to deal
  70. correctly with a change in the amount of memory available to it.
  71.  
  72. This could happen in one of two ways:
  73.  
  74.      *  The run-time library of the current language could provide a routine
  75.         to call Wimp_SlotSize and adjust its idea of the memory slot size.
  76.  
  77.      *  The application program could call Wimp_SlotSize to give itself an
  78.         extra area of memory above that used by the run-time language
  79.         library, in which it could (for example) operate a compacting heap,
  80.         which could grow and shrink as required.  Here one must assume that
  81.         the run-time language library does not re-read the values of
  82.         MemoryLimit (using OS_GetEnv or OS_ChangeEnvironment), since this
  83.         will be constantly changing.
  84.  
  85. The first technique is used by the BASIC 'END = &xxxx' construct, while
  86. ArcEdit operates the second system to give itself memory to put text files
  87. in.
  88.  
  89. The '*WimpSlot' command allows a *Obey file to specify the minimum and
  90. maximum amounts of memory required for an application (it calls
  91. Wimp_SlotSize).  For further details, see Wimp.Obey and Wimp.Install.
  92.  
  93.  
  94. Interactive slot resizing
  95. -------------------------
  96.  
  97. The Switcher utility provides a 'task window' which allows the user to drag
  98. various memory slots around in order to alter the allocation of memory within
  99. the machine.  Those slots which can be dragged are coloured differently from
  100. those which are for information only, and they include the Wimp's next and
  101. free slots, as well as the font area and so on.
  102.  
  103. It is also possible for an application to tell the Switcher that it would
  104. like to allow the user to dynamically change the amount of memory allocated
  105. to it.  This would be useful if, for example, a program could run with as
  106. much or as little memory as required, using disc cacheing to provide more
  107. memory.  In this case the speed of the system would depend on how much memory
  108. was available, so this would have to be a user choice.
  109.  
  110. Note: the following discussion assumes knowledge of the Wimp's message
  111. passing facilities, detailed in Wimp.Messages.  The exact format of the
  112. message blocks is also to be found there.
  113.  
  114. When the Switcher gets a Message_TaskInitialise (&400C2) message from the
  115. Wimp to indicate that a new task has started up, it sends a Message_SetSlot
  116. (&400C5) message to the task, with the 'new current slot size' field set to
  117. -1.  If the task fails to acknowledge the message, the Switcher will change
  118. the colour of its task slot to indicate that it cannot be dragged, and will
  119. refuse to let the user drag it.   If the task wishes to allow its slot to be
  120. dragged, it should acknowledge this message, and should respond to further
  121. Message_SetSlot messages by acknowledging them and calling Wimp_SlotSize with
  122. R0=new slot size, R1=-1.
  123.  
  124.  
  125. Claiming the Wimp's free memory pool
  126. ------------------------------------
  127.  
  128. A call is provided by the Wimp to allow programs such as ADFS to temporarily
  129. claim the Wimp's free application memory for operations such as backing-up a
  130. disc.  The call is similar to OS_ClaimScreenMemory:
  131.  
  132.         Wimp_ClaimFreeMemory
  133.         Entry:  R0 = 0 for release, 1 for claim
  134.                 R1 = amount of memory required
  135.         Exit:   R1 = amount of memory available
  136.                 R2 = start address of memory
  137.                 R2 = 0 means that the memory was not claimed (not enough)
  138.  
  139. NB: Only programs running in SVC mode can access the Wimp's free pool, since the    pages are protected against USR mode access (read or write).
  140.  
  141. Note that while the Wimp's free memory is claimed, it cannot give memory up
  142. to the RMA, screen, system area or current slot.  It is therefore extremely
  143. important that the memory is released after use, and it is recommended that
  144. the program using the free memory does not call much other code while it has
  145. the memory claimed (eg. code which claims blocks in the RMA).
  146.  
  147.